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Communications Network 



The present invention relates to a communications network and in 
particular to a circuit-switched network such as an ATM (Asynchronous Transfer 
5 Mode) network. 

Conventionally, networks using packet-based protocols such as Internet 
Protocol (IP) have functioned on a best effort basis. As a result, quality of service, 
as measured by such parameters as packet loss and latency, has varied 
considerably depending on the loading of network resources such as routers. 
10 While such variation is acceptable for some applications, such as Email, it is 
potentially a barrier to the use of internet Protocol for more critical applications 
such as voice telephony or multimedia conferencing. Accordingly, considerable 
effort has been directed to providing improved Quality of Service (QoS). One 
approach has been to supplement IP with QoS-related protocols such as ReSource 
15 reservation Protocol (RSVP). Another approach has been to make use of circuit- 
switched networks, and particularly ATM networks to carry IP traffic. When a 
customer terminal and a data source are both connected to an ATM network, then 
a Switched Virtual Circuit (SVC) may be used to "cut-through" from the terminal to 
the source, bypassing any intermediate routers, and providing a uniform and 
20 predictable QoS level. However, establishing a switched virtual circuit is a 
complex operation requiring the setting of a number of service parameters and this 
presents a barrier to the widespread adoption of this technique, despite its 
advantages. 

According to a first aspect of the present invention, there is provided a 
25 digital signal encoded with a Uniform Resource Locator (URL), the uniform resource 
locator comprising an identifier part identifying a resource as being accessible via a 
circuit-switched network, an address part comprising the address of the resource, 
and a service parameter part. 

URL's, as their name suggests, provide a standard system for identifying 
30 the location of resources on a network such as the Internet. They are commonly 
in the form <scheme> : <scheme-dependent-in format/on > , where scheme 
identifies the type of resource and may be, for example, http, or ftp and the 
scheme dependent information is conventionally a network address and a file 
path. The present invention by providing a URL scheme that is specific to 




resources on a circuit-switched network, and by including in the URL not only 
address information but also service parameters, makes it possible to set up 
circuits in a circuit-switched network with far greater ease than has been possible 
hitherto. The invention is particularly advantageous in the context of an ATM 
5 network, but might also be applied to other types of networks, such as, for 
example, a frame-relay network. 

According to a second aspect of the present invention, there is provided a 
method of operating a terminal connected directly or indirectly to a circuit-switched 
network, the method including: 
10 a) reading a URL comprising a circuit-switched identifier part identifying a resource 
as being accessible via a circuit-switched network, an address part comprising the 
address of the resource, and a service parameter part 

b) subsequently establishing a connection between the customer terminal and the 
resource, the connection having properties determined at least in part by one or 
1 5 more parameters contained in the service parameter part. 

Preferably the method includes reading the URL from a server remote from 
the terminal. Although the URL may be read from a local source, such as a 
browser bookmark file, the present invention is particularly advantageous when 
used withr-URL's which are supplied to the terminal from a remote server. The 
20 server, unlike the terminal, will generally have details of the nature of the resource 
in question and is therefore able to set the service parameters accordingly. For 
example, if the resource is a high quality video data stream needing a high 
bandwidth connection then the server may set correspondingly high service 
parameters in the URL. 
25 Preferably step (b) is initiated by the terminal. 

The invention also encompasses a signal carrier carrying a signal in 
accordance with the first aspect of the invention, and customer terminals and 
network servers arranged to use the URL's of the invention. 

Systems embodying the invention will now be described in further detail, 
30 by way of example only with reference to the accompanying drawings, in which: 

Figure 1 shows a network embodying the invention; 

Figure 2 is a flow diagram; 

Figure 3 shows a Graphic User Interface (GUI); and 
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Figure 4 shows a state machine for a client application implementing the 
invention. 

As shown in Figure 1 , a communications system includes an ATM network 
1. A customer terminal 2 is connected via the ATM network to an Internet Service 
5 Provider (iSP) 3 and to the public Internet. Via the Internet the customer terminal 
can connect to other end user customer terminals 4, 5 and to content provider 
data servers 6,7. One of the data servers 6,7 is also connected to the ATM 
network 1 . 

In use, the customer terminal 1 runs a client application that, in this 
10 example, is a web browser. The web browser is modified to support Windows 
Socket v2 (WinSock2) functionality, enabling ATM SVC's to be established and 
^ released in addition to TCP/IP or UDP/IP flows. In a conventional fashion, the web 

browser reads a web page served, for example by the data server 7. This web 
page includes links to resources stored on the data server. These links may 
15 include, for example, URL's for a number of MPEG-encoded video files. These 
URL's use an implementation of the ATM URL scheme of the present invention. 
The format of the ATM URL is described in further detail below. The URL contains 
the ATM network address of the server and the path on the server for the 
corresponding file, together with ATM service parameters. When the user of the 
20 customer terminal 1 clicks on one of these links, the URL is returned by the server 
to the web browser on the customer terminal. The customer terminal reads the 
ATM address and the service parameters from the URL, and then outputs signals 
£ into the ATM network in order to set up a switched virtual circuit to the specified 

address. Some of the service parameters may be marked in the URL as being user- 
25 defined. In this case, the web browser displays a window (also termed the "ATM 
GUI") that indicates to the user options for the user-defined settings. The user 
enters values in boxes in the window, or accepts default settings, and these values 
are added to the service parameters already defined in the URL. 

It should be noted that the HTTP server and the ATM server can reside on 
30 the same, or on physically separated computers. 

The general format of a URL is defined in the IETF (Internet Engineering 
Task Force) publication RFC (Request For Comments) 1738. URL's are defined as 
a sub-part of Universal Resource Identifiers, which are defined in IETF publication 
RFC1630. The format of a URL as defined in RFC1738 is: 
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< scheme > : < scheme-dependent-information > . 
An URL contains the name of the scheme being used (< scheme >) followed by a 
colon and then a string (the < scheme-dependent-information > ) whose 
interpretation depends on the scheme. Schemes that are currently widely used 
5 today on the Internet include, "http", "gopher", "ftp", and "news" etc. The 
purpose of these schemes is to inform the end user and/or the application of what 
type of resource is trying to be accessed and/or what mechanism shall be used to 
obtain that resource. The format of each of the scheme dependent information is 
reliant on the type of scheme used. For example, the scheme dependent 
10 information for HTTP is different from that used by FTP. However, most schemes 
do consist of the following information: 

• the name and domain of the server where the file resides, plus 

• the "location or path" to the file. 

1 5 Therefore many URLs for HTTP, FTP and Gopher resources are expressed as, 
scheme://server.domain/full.-pa i th.-oUfile^ 
where the schemers *separ*ated^frorn~the .Internet addness«of the server by two 
forward slashes ■,(//) and*t.he-lntennet address is separ.ated4rom-the full path to the 
file with a single forward* slash**/). 
20 This embodiment^of the present- invention- uses a new URL scheme, 

termed the ATM URL. In the syntax of this scheme, URL's for resources on an 
ATM network are identified by the string atm://. The scheme-dependent 
information in this case is of a different type to that used in conventional URL 
schemes such as those identified above. The scheme dependent information is 
25 divided into two segments. The division between the two segments is marked by 
a separator character. In this embodiment, the separator character is 
although the scheme might alternatively be implemented using other separator 
characters. An ATM URL has the following format: 

atm:// ATM parameters ©Server ATM address.sub-address/full-path-of-file 
30 The first segment is where the ATM parameters are located. The second segment 
contains the ATM server address. The ATM parameters and the ATM server 
address are separated by the '@' character. The format of the file path remains 
unchanged and is separated from the ATM server address by a single forward 
slash. The ATM server address can be specified in a number of ways : 
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• Native E.164 addressing scheme, as defined in ITU-T Recommendation E164 
(May 1997) 

• An ATM End System Addressing (AESA) scheme 
5 • A name-based address. 

When a name-based address is used, then the client application uses a domain 
name server to resolve the name into a corresponding network address. 

10 The use of sub addressing for either E.164 or AESA addressing scheme is optional 
in the URL. This is achieved by separating the ATM server address and the sub- 
address by the '.' character, thereby extending the length of the ATM server 
address field. This ATM format still enables search strings to be carried out, such 
as by appending a '?' character to the end of the file path. 

15 Table 2 below identifies the ATM parameters which are specified within 

the server. domain section of the ATM URL. The ATM parameters are coded from 
left to right. These ATM parameters represent the main Information Elements (lEs) 
specified in the ATM-F UNIv3.0, UNIv3.1, UNI v4.0, UNI v4.1 and ITU-T Q.2931 
signalling protocols. As shown in Table 2, the length of certain ATM parameter 

20 fields can vary. Therefore, to ensure that the web browser can reliably decode the 
information within the URL, each parameter is separated from another by a key 
character. In this embodiment the V character is used to delimit the different ATM 
parameters within the URL. It should be recognised that the V character is not the 
only key character which could be used. Other key characters such as '@\ '?', 

25 V or 'V could be used. RFC 1783 contains more information on using key 

characters. 

Only one instance of each field is defined in the ATM URL, i.e. the fields 
are not repeated. This is due to the fact that the corresponding information can 
only be present once in the ATM signalling SETUP or LEAF SETUP REQUEST 
30 message. 

The WinSock2 SPI is responsible for coding the ATM information into the 
correct format to be used by the underlying ATM signalling protocol. More 
information regarding the WinSock2 Specification is given in WinSock 2.0 
Specification, May 1996, version 2.2.0. The WinSock2 SPI is responsible for 



adding the additional mandatory ATM IBs, which are not present in the ATM URL, 
but are required by the underlying ATM signalling protocol. 

The underlying signalling protocols are responsibility for any interworking 
between different signalling systems protocols. It is the responsibility of the 
5 signalling protocol and not the application (i.e. web browser) to verify that the user 
selected functionality can be supported by the network. 

The abbreviations used in Table 2 are listed in the glossary below. 
The functionality and coding of the ATM parameters shown in Table 2 will 
now be described. 

1 0 UNI Protocol Version Field 

A number of different ATM UNI signalling protocols may be supported by the ATM 
server, and by the web browser. The ATM URL has a field describing what 
protocol or protocols are supported by the ATM server. This technique results in 
fewer interworking problems, and more successful call establishment attempts, 

1 5 between the web browser and the ATM server(s). 

Connection Topology, Field 

Three different- connection topologies , are identified, as defined- in UNIv3.1 and 
UNI4.0/4.1. These include point-to-point; point-to-multipoint and Leaf Initiated Join 
(LIJ). If the server has .indicated one of these connection topologies, then the user 
20 is not able to change it within the ATM GUI. If however, this field is coded as 
'User defined' then the user can select any topology provided it is supported by 
the protocol. 

UN.V4.0 (ATM FORUM af-sig-006 1 .000, defines 2 types of UJ connections. 
25 These are known as Network LIJ connections and Root LIJ connections. In the 
present example, only the Network LIJ connections shall be supported. 

As defined in UNIv4.0, in the context of an LIJ connection, it is the network that 
selects the ATM parameters such as, bandwidth QoS, traffic types etc. and not 
30 the Leaf, (i.e. the web browser). If the ATM URL is coded as a LIJ connection, 
then only some of the ATM parameters are required by the web browser. These 
ATM parameters includes, 
• LIJ Call Identifier; 



• ATM server address information (i.e. the Called Party Number); 

• ATM address of the web browser (i.e. the Calling Party Number). 

Like the Call Reference value, the LIJ Leaf Sequence Number value is internally 
5 generated by the web browser's signalling protocol stack and therefore does not 
need to be transferred within the ATM URL. 

LIJ Call Identifier Field 

The LIJ Call Identifier, is used with the called party number to uniquely identify a 
LIJ call at the root interface. As defined in UNIv4.0, the LIJ Call Identifier value 
10 shall be expressed as an 32-bit integer. Therefore valid values of the LIJ Call 
Identifier, range from 0 - 4294967296 (i.e. 0-2 32 ). 

AAL Type Field 

Above the ATM layer there are a number of ATM Adaptation Layers, supporting 
15 different functionality that can be used. This example allows the following AAL 
types to be coded in the ATM URL:- 



AAL Type 1 as defined in ITU-T Recommendation 1.363.1; 
AAL Type 2 as defined in ITU-T Recommendation 1.363.2; 
AAL Type 3/4 as defined in ITU-T Recommendation 1.363.3; 
AAL Type 5 as defined in ITU-T Recommendation 1.363.5; 

The WinSock2 SPI will add additional AAL information to the AAL IE, such as 
forward and backward maximum CPCS_SDU size, MID range and SSCS type etc. 
25 The UNIv4.0 specification and ITU-T Q.2931 recommendation define a list of AAL 
parameters that are used for signalling between two peer entities. 

Bearer Capability Field 

With ATM connections there are a number of different bearer capabilities, which 
30 can be used depending on the type of service being supported. This example 
allows the following bearer capabilities to be coded in the ATM URL:- 



20 



Bearer Class BCOB-A; 
Bearer Class BCOB-C; 
Bearer Class BCOB-X; 
Virtual Path (VP) service* 
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Service Category Field 

ATM allows a number of ATM Transfer Capabilities (ATC) or Service Categories to 
be specified. Table 1 below shows the different ATC or service categories 
10 supported by the ATM-F and the ITU-T. 
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ITU-T 1.371 
ATM Transfer Capability 


ATM Forum TM 4.0 
ATM Service Category 


Deterministic Bit Rate (DBR) 


Constant Bit Rate (CBR~) 


See below 1 ^ 


Real Time Variable Bit Rate (rt-VBR)™ 


Statistical Bit Rate (SBR) 


Non-Real l ime VBR (nrt-VBR) 


Available Bit Rate (ABR) 


Available Bit Rate (ABR) 


See below 2 


Unspecified Bit Rate <U BR) 


ATM Block Transfer (ABT) 


(no equivalent), 



Table 1 ATCs or Service Categories supported by the ITU-T 

■ and ATM-F 



Different ATCs or Service Categories are defined by various traffic parameters. For 
example CBR and UBR conformance definitions are defined by just the Peak 
Bandwidth, whereas VBR is defined by the Peak and Sustainable bandwidth, plus 
20 the Maximum Burst Size (MBS). 

Fwd & Bwd Peak & Sustainable Bandwidth plus MBS Fields 

The Peak and Sustainable bandwidth values (for both forward and backward 
directions) can either be set to 'User Defined' or Server Defined'. If they are coded 
as user defined then it is the responsibility of the end user to enter their desired 
25 values. If the web browser detects that a field is coded as 'User Defined' it shall 
invoke the ATM GUI enabling the user to enter the appropriate values. If however 



VBR-rt is equivalent to ITU-T SBR with QoS class 1. 
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the forward or backward bandwidth values are coded as 'Server Defined' then the 
server has already chosen values for the appropriate forward and backward 
bandwidth fields. It is possible to code the forward Peak/Sustainable bandwidth 
value as 'User Defined' but the backward Peak/Sustainable bandwidth value as 
5 'Server Defined' and vice versa. The same principles apply to the forward and 
backward MBS. 

Fwd & Bwd QoS Fields 

The forward and backward QoS can either be chosen by the server or by the user. 
If coded as 'User Defined' then the user shall via the ATM GUI select which QoS 

0 values are appropriate, otherwise the QoS values are selected by the server. The 
QoS classes are the same as defined in ATM-F UNIv3.1 therefore, Class 1 
represents the highest quality, whilst, 4 is the lowest quality. Class 0 represents 
'Unspecified' QoS and is used in conjunction with UBR. It is possible to code the 
forward bandwidth value as 'User Defined' but the backward bandwidth value as 

5 'Server Defined' and vice versa. 

All the ATM signalling protocols supported in this patent allow QoS classes to be 
signalled. However UNIv4. 0/4.1 also allows, as an option for individual QoS 
parameters values to be signalled. Therefore within the QoS field of the ATM URL, 
the support of individual QoS parameters can be specified. It is however, the 
responsibility of the end user or application to supply the values for the individual 
QoS parameters. More information regarding the signalling of individual QoS 
parameters is given in the UNiv4.0 specif ication.* - v ~ " 

Tagging Field 

The tagging of ATM cells is a functionality supported by both the ATM-F UNIv4.0 
and also ITU-T Recommendation Q. 2961. 6. The tagging of ATM cells, means 
lowering the priority of cells from CLP = 0 to CLP= 1 when they are deemed to be 
in breach of their traffic contract. It should be noted that ATM-F UNIv4.0 and ITU- 
T Q. 2961. 6 differ in their approach to tagging. ATM-F UN!v4.0 signalling protocol 
supports local tagging and uses octet 1 7 of the Broadband Bearer Capability (B-BC) 



2 ITU-T Q.296I. I Annex A allows as an option the support of UBR. 
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IE to denote whether forward or backward tagging is applicable. ITU-T Q.2961.6 
does not use octet 17 of the B-BC IE, but, defines two additional Broadband 
Transfer Capability code-points, in (octet 5a) of the B-BC IE to support global 
tagging. Interworking between ATM-F UNIv4.0 signalling protocols and ITU-T 
5 Q.2961.6 signalling protocols is outside the scope of this patent. It is the 
responsibility of the WinSock 2 SPI, to code the signalling message to support 
tagging depending on which signalling protocol is supported* 



Negotiation Field 

10 The negotiation of ATM traffic parameters is a signalling functionality supported by 
both ATM-F UNIv4.0 and also ITU-T Recommendation Q.2962. The ATM signalling 
negotiation allows for either an Alternative ATM traffic descriptor value or a 
Minimum Acceptable ATM traffic descriptor to be specified. It should be noted that 
both values can not be specified simultaneously. The user may choose the values 

15 for the Alternative or Minimum Acceptable ATM traffic descriptors manually via 
the ATM GUI, or this may be done automatically by the application. 

Modification Field 

ITU-T Recommendations Q.2963.1 and Q. 2963. 2 allow the forward and backward 
ATM traffic descriptor values (i.e. the cell rates) to be modified during the active 
20 part of the call. This functionality is only available in ITU-T signalling protocols and 
not in the ATM-F signalling protocols. Q.2963.1 is intended to be used for only 
CBR type connections whereas Q.2963.2 is intended to be used for VBR type 
connections. In order for the web browser to know whether the modification 
functionality is supported by the ATM server this information needs to be coded in 
25 the ATM URL. As the web browser can determine the service category from the 
ATM URL, only one value is required for the modification field. The user may 
manually invoke this modification process to either increase or decrease the cell 
rate, via the use of the ATM GUI or this may be done automatically via the 
application which is using the ATM SVC. If the user manually invokes the 
30 modification procedures, then the appropriate functionality would need to be 
supported in the ATM GUI. 

In relation to the parameters listed in Table 2, it should be noted that the 
value for the Peak and/or Sustainable Cell Rate and Maximum Burst Size are 
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dependent upon the limitations of the physical layer and the capabilities of the 
ATM switch(es) used for the SVC. If any of the functionality listed in the table is 
not supported by the ATM server, then, this is indicated by the character ' x \ 
Unlike the underlying signalling information elements (lE's), the parameters listed in 
5 the table are position dependent, as they have no proceeding identifier. The Calling 
Party Number, is not shown in the Table, The ATM server acdress will be mapped 
into the Called Party Number IE by the WinSock2 Service Provider Interface (SPI). 

ABR information fields carried in the ABR Setup Parameters IE, are only 
optional in the user to network direction, as defined in UNIv4.0. Therefore this 
10 information carried in the ABR Setup Parameters is not defined within the ATM 
URL. This does not preclude the calling party to include the ABR Setup Parameters 
™ IE in a SETUP message. 

ABR information, which is carried in the ABR Additional Parameters IE, is 
only optional in the user to network direction when the user wants to specify 
15 explicitly a set of ABR additional parameters as defined by UNIv4. Therefore this 
information carried in the ABR Additional Parameters IE is not defined within the 
ATM URL. This does not preclude the calling party including the ABR Additional 
Parameters IE in a SETUP message. The allowable combination of traffic 
parameters, QoS and bearer capabilities shall be in accordance with the UNIv4.1 
20 specification 

The negotiation of the ABR parameters is possible in this implementation, 
provided that the negotiation field within the ATM URL is coded accordingly. 
0 UNIv4.1 and ITU-T CL2961 .3 define which ABR parameters can be negotiated. 

As no Conformance Definition currently makes use of the PCR (CLP — 0) 
25 category, then this is not supported in the coding of the ATM URL. 

An example of an ATM URL coded in accordance with Table 2 is as 

follows: 

atm://1. 1.x. 5. 2.2. 1 .500.x. x. 375.x. 32.250.x. x. 187.x. 64. U 1 ,x.x.x@4701 0203040 
30 50607 080S000a0b0c0d0e0f0 1 020304/public/video.mpg 

The characteristics of a corresponding ATM SVC (switched virtual circuit) are as 
follows: 

• Server supports ATM-F UNIv3.1 ; 
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• Connection Topology type is point-to-point; 

• LIJ Call Identifier value is not supported, as point-to-point connection required; 

• AAL type is of typeB; 

• Bearer Capability-is of BCOB-X; > 

5 • VBR service category selected by server; 

• Forward Peak bandwidth (CLP = 0+ 1) value defined by the server; 

• Forward Peak bandwidth {CLP = 0 + 1 ) value is 500 Kbits/s; 

• Forward Minimum Bandwidth not used, (i.e. No ABR as VBR selected); 

• Forward Sustainable bandwidth (CLP = 0 + 1) is not used; 

10 • Forward Sustainable bandwidth (CLP = 0) value defined by the server is 375 
Kbits/s; 

• Forward MBS (CLP = 0+ 1) is not used; 

• Forward MBS (CLP = 0) value defined- by the server is 32; 

• Backward Peak bandwidth (CLP = 0+ 1) value defined by the server; 
15 • . Backward Peak bandwidth (CLP = 0 + 1 ) value is 250 Kbits/s; 

• Backward Minimum Bandwidth not used, (i.e. No ABR as VBR selected); 

• Backward Sustainable band width, (CLP = 0 + 1) is not used; 

• Backward Sustainable bandwidth (CLP = 0) value defined by the server is 187 
Kbits/s; 

20 • Backward MBS (CLP = 0 + 1 ) is not used; 

• Backward MBS (CLP = 0) value defined by the server is 64; 

• Forward QoS class defined by the server is class 1; 

• Backward QoS class defined by the server is class 1; 

• Tagging is not supported; 
25 • Negotiation is not supported; 

• Modification is not supported; 

The server address is specified in the AESA scheme, with the following value: 
30 • 470 1 02030405060708090a0b0c0d0e0f 0 1 020304 



The path and name of the file is public/video. mpg. 
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Figure 2 is a flow diagram illustrating in further detail the behaviour of a 
system operating using ATM URL's. The steps shown are as follows: 

1. The user searches web pages for the relevant information, as if using a 
standard web browser. No ATM SVC has been established. 

2. When the user clicks on the desired ATM Hyperlink/URL or uses a bookmark, 
the web browser performs the following operations:- 

3. First the Web browser has to determine that this is an ATM URL request, if so, 
it has to parse/decode the ATM information. This information is stored and 
used to help construct the profile of the signalling message capability, plus 
determine the socket and protocol state machine type. It should be noted that 
the ATM URL does not contain all the ATM lE's defined in the signalling 
protocols supported by this patent. This is due to two reasons. Firstly, not all 
the defined lE's are sent in the ATM signalling SETUP or LEAF SETUP 
REQUEST messages. Secondly, the ATM information within the URL contains 
only the information required by the web browser. The web browser or the 
WinSock2 API is free to add valid additional ATM information before initiating 
the ATM SVC. An example of this additional ATM information could be the 
Calling Party Number, Calling Party Sub-address, Transit Network Selector 
(TNS) Broadband Sending Complete, Broadband Repeat Indicator, Broadband 
High and Low Layer Information, Narrowband High and Low Layer Compatibility 
etc. Before data can be sent between the two entities, the web browser has to 
use the correct protocol state machine implementation for the URL scheme. 
The ATM protocol state machine has to be also associated with the ATM 
socket descriptor. As the URL scheme is 'atm://' the web browser knows it 
should use the ATM protocol state machine and create ATM sockets. The 
state machine is used by the web browser to define its behaviour when 
sending and receiving data over a connection. This state machine has been 
developed for use with ATM connections. The ATM state machine is 
described in further detail below with reference to Figure 4. 

30 4. If however, the web browser client determines after decoding the ATM URL 
that no ATM parameter value(s) need to be specified manually by the Web 
browser then, the ATM GUI is not launched and the Web browser uses the 
underlying WinSock2 Application Programming Interface (API) functionality to 
establish an ATM SVC to the desired destination. The characteristics of this 
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ATM SVC will be the same as those values returned from the HTTP server in 
the ATM URL. This corresponds to state ATM_GET SETTINGS in Figure 4 
5. If the user is required to define a particular ATM parameter va.ue(s), the web 
browser launches - the ATM GUI shown in Figure 3. This ATM GU. is an 
extens.cn to traditional web browser applications, in that it al.ows the end 
users to enter values for the ATM parameters coded as 'User De fi ne£r within 
the ATM URL. The values entered by the end user via the ATM GU. are also 
stored to help build the profile or characteristics of the signing messages 
wh.ch will be sent to the ATM server(s). This corresponds to state ATM GET 
SETTINGS in Figure 4. 

6. WinSock2 is responsible for creating ATM sockets for the web browser and 
ATM server to communicate via. This involves the web browser and ATM 
server to invoke a number of WinSock2 function cal.s. When the ATM sockets 
have been created but not connected together, then this corresponds to state 
ATM_BEGIN_CONNECT, as shown in Figure 4. 

7. Once the server and client ATM sockets are created, WinSock2. communicates 
w,th the underlying signalling, protocol stack to establish an ATM SVC and 
lofl-callv connects the two ATM sockets together. The ~.WinSock2 SP, is 
responsible for -taking the ATM URL parameters, p, US possible information added 
by the user and coding them into the correct format to be used with the 
underlying sig na „i n g protocol , be jt UN , v3 Q ^3 ^ i ^ 

Q.2931. The WinSock2 SP. is also responsible for including mandatory 
S.gna.ling lE's, not defined in the ATM URL. Examples of these mandatory | E 's 
mclude, the Protocol Discriminator. Call Reference, Message Length, Message 
Type and Endpoint Reference (for Point-to-Multipoint connections) p,us LIJ 
Sequence Number (for L.J connections,. ,f the ATM SVC is successfully 
estabhshed then, charging records for that connection can be generated and 
state ATM SEND_REQUEST is entered, see Figure 4. if however, the SVC fails 
to be established, the web browser .aunches a window to inform the user of the 
event and enters the ATM_ERROR_FOUND state. 



8. Once the ATM SVC is established, data can be sent and received between the 
web browser and the ATM server. Before the fi. e|s , are downloaded the ATM 
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server returns the total length of the file to be downloaded to the web browser. 
The number of bytes of data received by the web browser is incremented and 
compared with the file size obtained at the GET_F!LE_SIZE state, of Figure 4. 
if the two values are equal, then the whole file has been transferred and the 
ATM_TRANSFER_STOP state is entered, else the transfer continues. When 
downloading data, control is passed back from the state machine to the calling 
application, so it won't block user commands. Knowing the size of the file, 
allows the web browser to display the transfer progress status (indicating the 
proportion of bytes received compared to the total number yet to be received) 
and to estimate the remaining time of the transfer. As many different types of 
data can be downloaded, the web browser has to know how to interpret each 
type of data. Depending on the associated Multipurpose Internet Mail 
Extensions (MIME) type, the data is directed to either a plug-in application, a 
file name on a local or remote disc, or to the web browser display. 

9. If errors occur during the download process, the state machine enters the 
ATM_ERROR_DONE state. This may occur for several reasons, such as, the 
ATM server did not send the size of the file in the first packet; or the transfer 
of a buffer cannot be completed because either there was a network or 
application failure etc. 

10. If the user wishes to terminate the file download, they can, by pressing the 
'CANCEL' button on the progress dialog box or alternatively by pressing the 
'STOP' button on the web browser GUI. This causes the state, ATM ERROR 
to be entered, as shown in Figure 4 and causes the ATM SVC to be released. 
In addition, providing there is end-to-end support between the web browser and 
the ATM server to support ITU-T Rec. Q. 2963.1, or Q.2963.2 and (Q.2725.2 
or Q2725.3) signalling, then the end user can modify the traffic characteristics 
of the ATM SVC. This modification process can be achieved via the use of the 
ATM GUI and the user entering new information or automatically by the 
application, which could be transparent to the user. Figure 3 shows more 
information. 

11. Once the file(s) have been downloaded to the web browser, the ATM server 
automatically starts the first step to close the ATM sockets. By closing the 
sockets causes the ATM server in turn, to release the ATM SVC between itself 
and the web browser. Any charging mechanisms associated with the SVC 
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should be stopped. The web browser is now in the ATM_TRANSFER_STOP 
state, as shown in Figure 4. 
12.0nce the ATM SVC has been released, the server and client can then 
completely shutdown their ATM sockets associated with the SVC and release 
5 any resource(s) allocated to them. The web browser, is now in the 
FREE_ATM_RESOURCES state as shown in Figure 4 and-eoMrol is passed back 
to the calling process within the web browser. 

The preferred embodiment of the invention described above offers a number of 
10 benefits. It enables the dynamic bandwidth and QoS characteristics associated 
with ATM technology to be exploited, and, importantly helps to hide the 
complexity of establishing ATM SVCs from the end user. Therefore the processes 
involved in establishing an ATM SVC, can become almost transparent to the user. 
It is believed that this transparency or ease of use, will help drive the deployment 
1 5 of ATM SVC capability to end users. Therefore an.ATM based web browser could 
operate, in the^ame ■ mannewas>an*I.P^Veb Browser,, suchras Netscape Navigator 
and Micosoit lnter.net,Expl.orer, The HTTP^server storing the ATM URL of the file 
the use^wrshes.toi.etweve^ betWr f plaee^o-undePstand^he^TM characteristics 
required- by^the file, rather th«*th*and user. The-end-user -carvtiava full control of 
20 when anwAT'M SVC is established' and -released*,, by-using .the ATM Graphical User 
Interface (GUI). The endaser can also modify the ATM information in the URL, via 
the ATM GUI. As the ATM SVC is established from the user towards the server, 
it doesn't have any profound impacts on the traditional billing model. A high 
degree of independence from the underlying ATM signalling protocols is achieved. 
25 Therefore this ATM based URL concept can be used with either ATM-F or ITU-T 
ATM UNI signalling protocols. 
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TABLE 2 



Order 


L Description | Length ; . 


; ..-..O; Values ;-r. 




UNI Protocol Version 


2 


UNlv3.0=l; 
UNIv3.1=2; 
UNlv4.f>3; 
UNIv4.1=4; 
Q.293l=5; 

UNIv3.1 or UNtv3.0=6; 

UNIv3.1 or tTNIv4.0=7; 

UNlVj. I or U IN IV4. 1 =5; 

UNIv3.1 orQ.293l=9; 

UNIv4.0 or UNIv4.1 = 10; 

UNIv4.0 orQ.2931 = l !; 

UNIv4.I or 0.2931 = 12; 

Other values are reserved for 

further use. 




Connection Topology 


1 


User defined=C; 
Point-to-point= I ; 
Point-to-multipoint=2: 
Leaf Initiated Join=3; 

Other values are reserved for 
further use. 




LIJ Call Identifier 


1-10 


Range 0 - 4294967296 (i.e. 0- 
2 32 ). 

LIJ not Supporxed=x; 


4^ 


AAL Type 


1 


AAL type 1 = 1; 
AAL rype2=2; 
AAL type3/4=3; 
AAL type5=5; 

Other values are reserved for 
further use. 


5 th 


Bearer Capability 


1 


BCOB-A=0; 
BCOB-C=l; 
BCOB-X=2; 

VP_service=3; < 
Other values are reserved for ; 

further use. 


6 W 


Service Category 


1 


User defmed=0; 

CBR=1; 

VBR=2; 

VBR-rt=3; 

UBR=4; 

ABR=5; 

ABT=6; 

Other values are reserved for 
further use. 
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10 : ' 



12 th 



14« 



15" 



Forward Bandwidth Value 



Forward Peak Bandwidth 
(CLP=0+1) 



Forward Minimum Bandwidth 



1-7 



User defined=0; 
Server defined- 1. 
Other values 

further use. 



are reserved for 



Forward Sustainable Bandwidth 
(CLP=0+1) 



Forward Sustainable Bandwidth 
(CLP=0) 



Forward Maximum Burst Size 
(CLP=0+1) 



1-7 



1-7 



An integer value, expressed in Kbits/s, 
Range = 0- 71 13539. 



An integer value, expressed in Kbits/s, 
Range = 0 - 71 13539. 
Not Applicable=x; 



An integer.value, expressed in Kbits/s, 
Ranges 0- 71 13539. 
Not Applicable=x; 



Forward Maximum Burst Size 
(CLP=0) 



Backward Bandwidth- Value 



Backward Peak Bandwidth 
(CLP=0+1) 



1-7 



An integer value, expressed in Kbits/s, 
Range = 0 - 71 13539. 
Not Applicable=x; 



An integer value, expressed in cells. 
Range = 0 - 16777216. 
Not Applicable=x; 



An integer value, expressed in ceils. 
Range - 0 - 16777216. 
Not Applicable=x: 



User defined=0; 
Server defined== 1 . 
Other values 

further use. 



are reserved for 



An integer value, expressed in Kbits/s, 
Range = 0-71 13539. 
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18 th 



19* 



BackwardeMinimum Bandwidth 



Backward Sustainable Bandwidth 
(CLP=0+1) 



Backward Sustainable Bandwidth 
(CLP=0) 



Backward Maximum Burst Size 
(CLP=0^l) 



1-7 



1-7 



An integer value, expressed in Kbits/s, 
Range = 0-7113539. 
Not Applicable^; 



1-7 



1-8 



An integer value, expressed in Kbits/s, 
Range = 0- 71 13539. 
Not Applicable^; 



An integer value, expressed in Kbits/s, 
Range = 0 - 7113539. 
Not Applicable~x; 



An integer value, expressed in cells, 
Range = 0 - 16777216. 
Not Apphcable~x; 



21 s 



Backward Maximum Burst Size 
(CLP=0) 



1-8 



Forward QoS 



An integer value, expressed in cells. 
Range = 0 - 16777216. 
Not Applicab 1 e=x ; 



User defined-0; 
Classl = l; 
Class2=2; 
Class3=3; 
Class4 =4; 

Class Unspecifled=5; 
Individual QoS parameters=6; 
Other values are reserved 

further use. 



for 



09-12-1998 
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22 "c 


Backward QoS 


I 


User defined=0; 
Class 1 = 1; 
C!ass2=2; 
Class3=3; 
CIass4 =4; 

Class Unspecifled=5; 

Individual QoS parameters=6; 

Other values are reserved for 

further use. 


23 rc 


Tagging 


l 


User defined=0; 

Tag fwd cells=l 

Tag bwd cells=2 

Tag fwd+bwd cells=3 

Tagging Not Supported=x; 

Other values are reserved for further use. 


24 th 


Negotiation Type 


1 


User defined=0; 

Alternative ATM traffic descriptor^ 1 ; 
Min. Acceptable ATM traffic descriptor^; 
Negotiation Not Supported=x; 
Other values are reserved for 

further use. 


25 th 


Modification Supported 


1 


Modification supported= I ; 

Modification Not Supported=x; 

Other values are reserved for 

further use. 




i 
j 
| 

1 
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Glossary 

ABR Available Bit Rate 

ABT ATM Block Transfer 

5 ARP Address Resolution Process 

ATM Asynchronous Transfer Mode 

ATM-F ATM Forum 

B-HLI Broadband High Layer Information 

B-LLI Broadband Low Layer Information 

10 CBR Constant Bit Rate 

DNS Domain Name Service 

FR Frame Relay 

GUI Graphical User Interface 

HTML HyperText Marked-up Language 

1 5 HTTP Hyper-Text Transfer Protocol 

IE Information Element 

IETF Internet Engineering Task Force 

IP internet Protocol 

ITU-T International Telecommunications Union - Standardisation Sector 

20 PVC Permanent Virtual Circuit 

QoS Quality of Service 

RFC Request For Comments 

SPI Service Provider Interface 

SVC Switched Virtual Circuit 

25 TCP Transmission Control Protocol 

UBR Unspecified Bit Rate 

UDP User Datagram Protocol 

UNI User Network Interface 

URL Uniform Resource Locator 

30 VBR Variable Bit Rate 

VCI Virtual Channel Identifier 

VPI Virtual Path Identifier 

VPCI Virtual Path Connection Identifier 



21 



CLAIMS 

1. A digital signal encoded with a uniform resource locator (URL), the uniform 
resource locator comprising an identifier part identifying a resource as being 

5 accessible via a circuit-switched network, an address part comprising the address 
of the resource, and a service parameter part. 

2. A digital signal according to claim 1 , in which the uniform resource locator has 
the format: 

< circuit-switched identifier part >://< service parameter part >*< address part> 
where * is a predetermined separator character. 

3. A digital signal according to claim 1 or 2, in which the identifier part identifies 
the resource as being accessible via an ATM. network. 

4. A digital signal according to claim 3, in which the service parameter part 
includes ATM service parameters. 

5. A digital signal according to any one of the preceding claims, in which the 
20 service parameter part includes an identifier for a connection topology. 

6. A digital signal according to any one of the preceding claims, in which the 
service parameter part includes a parameter indicating a connection bandwidth. 

7. A machine-readable carrier carrying a signal according to any one of the 
preceding claims. 

8. A method of operating a terminal connected directly or indirectly to a circuit- 
switched network, the method including: 

30 a) reading a uniform resource locator, the URL comprising an circuit-switched 
identifier part identifying a resource as being accessible via a circuit-switched 
network, an address part comprising the address of the resource, and a service 
parameter part 
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b) subsequently establishing a connection between the customer terminal and the 
resource, the connection having properties determined at least in part by one or 
more parameters contained in the service parameter part. 

5 9. A method according to claim 8, including reading the uniform resource locator 
from a server remote from the terminal. 



10. A method according to claim 8 or 9, in which step (b) is initiated by the 
terminal. 

10 

11. A method according to any one of claims 8 to 10 in which the identifier part 
identifies the resource as being accessible via an ATM network, and the service 
parameter part contains one or more ATM service parameters. 

12. A terminal for use in a communications network including a circuit-switched 
15 network, the terminal including: 

a) a network interface for connection to the communications 
network; 

b) a processor arranged to carry out the following steps: 

i) reading a uniform resource locator (URL), the URL 
20 comprising a circuit-switched identifier part identifying 

a resource as being available via the circuit-switched 
network, an address part comprising the address of 
the resource, and a service parameter part; 

ii) subsequently establishing a connection between the 
25 customer terminal and the resource, the connection 

having properties determined at least in part by one or 
more parameters contained in the service parameter 
part. 



30 13. A data server for use in a communications network including a circuit- 
switched network, the data server including a store programmed with a digital 
signal according to any one of claims 1 to 6. 



:09-12^:998: 
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ABSTRACT 



A Uniform Resource Locator (URL) includes an identifier part that identifies the 
URL as being for a resource on a circuit-switched network, a service parameter 
5 part and an address part. A terminal reads the URL and establishes a connection 
to the resource. Properties of the connection, such as the bandwidth or the 
connection topology, are determined by values of service parameters in the service 
parameter part. 
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